Computer software programs are often designed to call (invoke) other programs. Generally the called program serves a function not provided as part of the calling program. The calling program is variously referred to as a “client” or a “parent” program and the called programs are referred to as “server” or “child” programs. For ease of explanation, the parent—child designations are used in the description that follows.
In order to call a child program, the parent program must know how to communicate with the child program, including how to call the child program, and what arguments or parameters to provide. In the prior art it is common for the parent program to call known child programs with which the parent program is already familiar, or to call child programs that have been designed to conform to a call format prescribed by the parent program. However, this requirement is too rigid for some applications which depend on child programs that are developed independently of the parent program.
For example, computer-aided circuit design (CAD) applications (the parent program) depend on the feedback of third-party simulation programs (the child programs) to compare circuits with their specifications via trial and error simulation and automatic iteration. The parent program provides the circuit design and the automatic iteration algorithm but relies on the third-party child program to do the simulation.
Another example is a computer network health check monitoring program, where the parent program provides a framework for checking different protocols, processing and saving data, and acting upon different criteria detected in the data. Typically, the parent program supports various protocol checking modules that work well with the parent program's framework. However, the user may want to add other protocol checking modules that do not work well with the parent program's existing framework, such as those developed by third parties, or those developed for new protocols that were not originally supported by the parent program. For example, the protocol modules may require completely different invocation methods or parameters, or may result in new actions when certain criteria are detected.
One approach to overcoming this problem is to have the parent program use one fixed entry point, or common interface, into the child program. This approach requires every child program to implement the common interface. An example of this method of extending a program is Microsoft's Component Object Model (COM). COM defines a standard for component interoperability that allows components made by different software vendors to be combined into a variety of applications. The COM components can include parent programs and child programs where the parent programs operate as clients of the child programs, and the child programs operate as servers.
In COM the parent and child programs interact with each other through a collection of functions, referred to as interfaces. The interfaces are defined using the COM Interface Definition Language (IDL). Each child program (COM server) uses a fixed entry point, or common interface, that must be implemented by all of the COM components, referred to as the IUnknown interface. Component-specific functions and interfaces are negotiated using the IUnknown interface. The COM components are registered in the Windows registry. When a parent program calls the child program, the Windows Service Control Manager (SCM) uses the entries in the Windows registry to invoke the child program (COM server component) according to the common interface.
One of the drawbacks to COM is that all of the parent programs (COM clients) wishing to call the child program (the COM server) must use the common IUnknown interface. Specifically, the parent program (the COM client) may require a fixed customized interface that each child program (COM server) must implement, and that interface must inherit the IUnknown interface. As a result, COM does not provide any flexibility in program invocation. That is, the parent program (the COM client) cannot vary the way in which it calls a child program (COM server). This lack of flexibility makes COM unusable in situations where the parent program (COM client) and the child program (COM server) are developed independently of one another, or where there is a need to vary the way in which the child program (COM server) is called.
Another drawback to COM is the lack of consistent user interface (UI). In COM, each child program (COM server) component provides their own UI. From the parent program (COM client) point of view, this means that each of the of the child programs it needs to call may provide a different look and feel, which may be cumbersome for the parent program to implement.